feat: 퇴사 근로자 안전 보관과 업무 차단 구현 - #199

왜 필요한가요?

체류기간 경과 확인과 실제 퇴사·고용종료는 서로 다른 판단입니다. 근로자를 자동 삭제하지 않으면서, HR이 고용종료와 남은 업무 정리를 확인한 뒤 운영 대상에서 안전하게 분리할 필요가 있습니다.

Depends on #198
Closes #193

무엇이 바뀌나요?

• GET /api/v1/workers/{workerId}/archive-eligibility로 보관 차단 사유를 확인합니다.
• POST /api/v1/workers/{workerId}/archive로 HR·ADMIN이 사유와 expected_version을 제출합니다.
• ACTIVE·ON_LEAVE, 미완료 Task, 대기 승인, 유효 Worker Link가 있으면 보관을 거부합니다.
• 보관 근로자는 기본 목록·AI 대상 탐색·신규 Task 대상에서 제외합니다.
• 기존 상세·Task·문서·응답·감사로그는 삭제하지 않습니다.
• 보관 시각·처리자·사유와 WORKER_ARCHIVED 감사로그를 저장합니다.
• 동시 Task 생성과 보관이 엇갈리지 않도록 근로자 행 잠금으로 직렬화합니다.
• V56에 보관 테이블, PostgreSQL V57에 RLS 정책을 준비합니다.

안전장치

• 체류기간 만료만으로 퇴사·불법체류를 자동 판단하지 않습니다.
• 자동 삭제·자동 보관·자동 개인정보 변경을 수행하지 않습니다.
• 다른 사업장 근로자는 404로 숨기며 VIEWER는 조회·보관할 수 없습니다.
• RLS 활성화는 공통 RLS PR에서 별도로 수행합니다.

검증

• ./gradlew test --tests com.fowoco.server.worker.WorkerArchiveIntegrationTest
• PostgreSQL 16 전체 테스트 688개 — 실패 0건
• 제한된 Runtime DB Role의 HTTP·Repository 격리 테스트 통과
• Flyway migrate·validate 및 보관 테이블·정책 계약 검증 통과
• git diff --check

병합 순서

1. 선행 PR 체류기간 만료 경과 긴급 확인 흐름 구현 #198 병합
2. 이 PR의 base를 main으로 변경
3. 최신 main 기준 CI·PostgreSQL 검증
4. Squash Merge